An application server acts as a set of components accessible to a programmer or developer through an API. An example application server is CICS® (Customer Information Control System) transaction server (TS) which is a product range of International Business Machines Corporation (IBM®) of Armonk, N.Y., United States. CICS TS operates under the z/OS® operating system. IBM, CICS and z/OS are trademarks of IBM.
An API is defined by a set of API commands which can be classified into different kinds of functionality. Typically some API commands will be quite general (e.g. authentication and password management, standard manipulations of containers or documents through insert, delete etc.), whereas others will reflect the detailed programming environment available for the particular application server (e.g. CICS business transaction services used to control the execution of complex business transactions). An API request is a code portion made up of one or more API commands that is sent to the application server to solicit an API response returning a result. In a situation where the application server cannot process the API request, the API response is in the form of an error code which hopefully provides some fairly specific information as to why the solicited response could not be generated.
Especially for large applications, modifying application code, e.g. to customize the code for a particular customer's needs, can be quite time consuming. For testing modified application code during development, it is often not possible or desirable to provide access to a full live system, or a full shadow test system. To assist developers or programmers in testing modified application code, the approach of so-called API mocking has gained popularity in recent times. API mocking refers to the idea of creating mocked-up versions of APIs for the purpose of testing modified application code, where the mocked-up API does not represent a fully virtualized copy of the real API, but rather simply includes enough functionality to create plausible API responses to API requests received from the application code being tested by the developer. Therefore the component with rewritten code that is to be tested “thinks” it is interacting with a remote service via a suitable API, but in fact the remote service is not present and the API is not the “real” API, but rather a mock API designed for the purpose of returning a plausible API response or cross-section or API responses to the component under test.
Another known approach is it use a user exit. A user exit is a bespoke program which modifies how a software component has been written to operate under standard conditions. They are used by customers to modify standard packages to provide customized functionality. For APIs, a user exit can be written which intercepts API commands on their way to the application program, and decides whether they should be routed onward to the application program with or without modification. However, the user exit program needs to be written, compiled, installed and tested, which represents a significant task which needs to be completed before the modified application code itself can be tested.